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
Where can I find a listing of the features that were added to Verilog in the 2001 version, and then of the ones added in SystemVerilog?Article: 148551
Steve Pope <spope33@speedymail.org> wrote: >Please look at the figure on page 11-28 of this document: > >http://www.busim.ee.boun.edu.tr/~resources/fdq.pdf Actually, there is a somewhat better Mathworks document on the subject here: http://www.mathworks.com/access/helpdesk_r13/help/toolbox/filterdesign/propref7.html#20164 In my experience, the most useful and well behaved forms of lattice filters are termed as follows in the above: "latticema" -- all-zero filter "latticear" -- all-pole filter "latticearma" -- filter with both poles and zeros SteveArticle: 148552
Hi every one I need to implement 100Mb ethernet connection on FX12 mini module for data transmission only. EDK 10.1 XPS Base System Builder gives me two options for ethernet connection (using powerPC) for memec FX12 mini module development board. Either use XPS LL TEMAC or XPS ETHERNET LITE. Can anyone kindly tell me the differences b/w the two approaches? and what will be the most suitable approach for me (w.r.t. easiness in implementation, resource utilization, liscenece issues etc)? Any help will be much appreciated. THANKS --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148553
On 31 Jul, 22:49, spop...@speedymail.org (Steve Pope) wrote: > Rune Allnor =A0<all...@tele.ntnu.no> replies to my post, > > >> I must say that I'm just not getting your point here. > >> Firstly, the FIR part of such a filter is not unstable. > >> The IIR part cannot be unstable if the coefficients are > >> constrained within the range (-1,1), a constraint that is > >> easily imposed by the implementation whether it be in RTL, > >> or gates, or software/firmware. > >Sure. You know that. I know that. But is that konwledge > >wide-spread? Would you trust users to depend on knowing > >these things? > > Yes, it's as widespread as any stability criteria for any > other filter topology. The other topologies only matter as the established baseline. We are focusing on the lattice topology here. > >> Other topologies have similar regions of instabilities for > >> their coefficient; but they are not stated as simply. > >Wrong. The IIRs are stable subject to poles staying > >strictly inside the unit circle. Zeros might be everywhere, > >no restrictions there. > > The same is true for a lattice topology, The pleas prove this statement mathematically. Up to this point you have been very persistent in restricting the reflection coefficients to the range [-1,1]. Could you pelase elaborate on what happens if the reflection coefficients stray outside that range? > >FIRs are unconditionally stable, at the outset. > >The lattice structure represents a dobule obfuscation in that it > >1) Places restrictions on FIR filter stability > > I have NO idea what you are talking about here. A lattice implementation fuses the IIR and the FIR into a common structure. That's why it is used in the AR-type perdictors: You get *both* the perdicted signal, as computed by the FIR AR predictor *and* the prediction error (as computed by the IIR predictor inverse) for a minimum ofcomputations. One constraint for this to work is that the IIR is stable. > >2) Depends on zero locations > > Again, you've lost me. =A0Your statements 1) and 2) are not true, > so far as I know. "As far as you know." Check it out. > >Again, I don't have my books easily available, so with the caveat > >that > >I'm writing off years-old memories: > >The FIR and IIR parts are tightly coupled in the lattice structure. > > Please look at the figure on page 11-28 of this document: > > http://www.busim.ee.boun.edu.tr/~resources/fdq.pdf > > The zero location are controlled by the coefficients v1, v2.... > These coefficients do not make the filter unstable. > > There is no "obfuscation" much less "double obfuscation". =A0This > is a perfectly normal, everyday, widely used filter with better > stability behavior than most. So why isn't it mentioned in every textbook out there? Why bother with DF I and II if the lattice works so well? RuneArticle: 148554
On 1 Aug, 05:10, spop...@speedymail.org (Steve Pope) wrote: > Steve Pope <spop...@speedymail.org> wrote: > >Please look at the figure on page 11-28 of this document: > > >http://www.busim.ee.boun.edu.tr/~resources/fdq.pdf > > Actually, there is a somewhat better Mathworks document on the > subject here: > > http://www.mathworks.com/access/helpdesk_r13/help/toolbox/filterdesig... > > In my experience, the most useful and well behaved forms of lattice > filters are termed as follows in the above: > > "latticema" -- all-zero filter > "latticear" -- all-pole filter > "latticearma" -- filter with both poles and zeros > > Steve Sorry - I got you wrong from the start. I had you down as knowing your DSP. This reveals your true guise as a mere matlab user. RuneArticle: 148555
Rune Allnor <allnor@tele.ntnu.no> wrote: >On 31 Jul, 22:49, spop...@speedymail.org (Steve Pope) wrote: >> >> Other topologies have similar regions of instabilities for >> >> their coefficient; but they are not stated as simply. >> >Wrong. The IIRs are stable subject to poles staying >> >strictly inside the unit circle. Zeros might be everywhere, >> >no restrictions there. >> The same is true for a lattice topology, >The please prove this statement mathematically. Personally I am satisfied with this well-known fact from filter theory, I feel that the literature is strong enough, and I do not feel on the hook to come up with a proof. > Up to this point > you have been very persistent in restricting the reflection > coefficients to the range [-1,1]. Could you pelase elaborate > on what happens if the reflection coefficients stray outside > that range? Internal states may saturate and stay there. Typically. >A lattice implementation fuses the IIR and the FIR into a >common structure. That's why it is used in the AR-type >perdictors: You get *both* the perdicted signal, as computed >by the FIR AR predictor *and* the prediction error (as computed >by the IIR predictor inverse) for a minimum ofcomputations. >One constraint for this to work is that the IIR is stable. > >> >2) Depends on zero locations >> >> Again, you've lost me. Your statements 1) and 2) are not true, >> so far as I know. >"As far as you know." Check it out. You haven't supported these statements. If there is a lattice topology whose stability depends upon the zero locations, please provide a cite for it. (I'm sure such a think might exist. But it is not a mainstream topology I would think.) >> >Again, I don't have my books easily available, so with the caveat >> >that >> >I'm writing off years-old memories: >> >The FIR and IIR parts are tightly coupled in the lattice structure. >> >> Please look at the figure on page 11-28 of this document: >> >> http://www.busim.ee.boun.edu.tr/~resources/fdq.pdf >> >> The zero location are controlled by the coefficients v1, v2.... >> These coefficients do not make the filter unstable. >So why isn't it mentioned in every textbook out there? >Why bother with DF I and II if the lattice works so well? It is covered in a fair fraction of textbooks. When I was in grad school, this was standardly taught to all students who took DSP courses that covered filter design. And, while Mathworks is not a gold standard or anything, what I regard as the three most useful lattice topologies, as well as three less useful one, are among the only sixteen "filter structure" properties they have defined. That seems a fairly significant representation -- one third of the filter toplogies they deigned to include in their suite are lattice filters. That is a fair indicator they are widely used. SteveArticle: 148556
Rune Allnor <allnor@tele.ntnu.no> wrote: >On 1 Aug, 05:10, spop...@speedymail.org (Steve Pope) wrote: >> "latticema" -- all-zero filter >> "latticear" -- all-pole filter >> "latticearma" -- filter with both poles and zeros >> Steve >Sorry - I got you wrong from the start. I had you down as knowing >your DSP. This reveals your true guise as a mere matlab user. Sigh. You're grasping at straws. The above is a good short reference on these topologies, useful to any designer, Mathworks-using or otherwise, which is why I posted the link. (I probably employ Matlab in fewer than 5% of the project I work on, and it has never been by my decision...) SteveArticle: 148557
On 1 Aug, 09:53, spop...@speedymail.org (Steve Pope) wrote: > Rune Allnor =A0<all...@tele.ntnu.no> wrote: > > >On 1 Aug, 05:10, spop...@speedymail.org (Steve Pope) wrote: > >> "latticema" -- all-zero filter > >> "latticear" -- all-pole filter > >> "latticearma" -- filter with both poles and zeros > >> Steve > >Sorry - I got you wrong from the start. I had you down as knowing > >your DSP. This reveals your true guise as a mere matlab user. > > Sigh. =A0You're grasping at straws. I'm not. Matlab has a very poor repurtation as academic reference. They used to estimate the length / duration of the impulse response of IIR filters as the number of numerator coefficients in the transfer functions (which works for FIR filters). Their IIR filter design procedures were screwed up to the point where one needed to 'unteach' students the matlab blunders before one could teach how things really were doing. Iterative methods like the Levinson recursion required users to supply 'true' AR orders up front, as opposed to supplying a *maximum* order and then use some order estimator within those constraints. At least that was the status when I last used the SP toolbox around 2004, and had been the status in the 15 years prior to that time. I know the SP toolbox has been reworked since then, but I doubdt that more than two decades worth of flaws, blunders and mistakes are corrected in a hurry. RuneArticle: 148558
On 1 Aug, 09:50, spop...@speedymail.org (Steve Pope) wrote: > Rune Allnor =A0<all...@tele.ntnu.no> wrote: > > >On 31 Jul, 22:49, spop...@speedymail.org (Steve Pope) wrote: > >> >> Other topologies have similar regions of instabilities for > >> >> their coefficient; but they are not stated as simply. > >> >Wrong. The IIRs are stable subject to poles staying > >> >strictly inside the unit circle. Zeros might be everywhere, > >> >no restrictions there. > >> The same is true for a lattice topology, > >The please prove this statement mathematically. > > Personally I am satisfied with this well-known fact from filter theory, > I feel that the literature is strong enough, and I do not feel on the > hook to come up with a proof. Again, I obviously had you wrong. This is a bout maths and engineering, not emotions. If you don't 'feel' up to substantiating your position, don't challenge the points made. > >> >2) Depends on zero locations > > >> Again, you've lost me. =A0Your statements 1) and 2) are not true, > >> so far as I know. > >"As far as you know." Check it out. > > You haven't supported these statements. =A0If there is a lattice > topology whose stability depends upon the zero locations, please > provide a cite for it. =A0(I'm sure such a think might exist. > But it is not a mainstream topology I would think.) This is well-known from statistichal DSP. I can't come up with specifc citations, as my library is is storage and will remain there for a few weeks to come, but I will tell you what to look for. I know this is treated in the Proakis & Manolakis general DSP text: When dealing with AR models, one can solve the Yule-Walker equations (or rather, and estimator for these equations) in any number of ways. Direct solutions through linear algebra will give you the straight-forward FIR prediction filter; the Levinson recursion will also give you the reflection coefficients that go directly into the lattice representation. As one would expect, there exist conversion formulae between the FIR and lattice representations for the AR model: Insert a set of FIR coefficients and crank out a set of lattice coefficients. And vice versa. The problem is the implicit constraints. In the AR application the FIR filter is guaranteed to be minimum phase, so its IIR inverse is causal stable. This translates directly to the lattice reflection coefficients being constrained to the interval <-1,1>. However, the unsuspecting incompetent user who stumbles across these conversion formulae and tries to convert a linear phase FIR to lattice form - don't ask *why* one would want to do this; I assume the user to be *incompetent* - would end up with a numerically unstable FIR. Which is a contradiction in terms, given the entry-level indoctrination matra of DSP. Which will only come back to haunt the designer, who exposed the incompetent user to the lattice structure in the first place. RuneArticle: 148559
On Aug 1, 5:53=A0am, Rune Allnor <all...@tele.ntnu.no> wrote: > On 1 Aug, 09:53, spop...@speedymail.org (Steve Pope) wrote: > > > Rune Allnor =A0<all...@tele.ntnu.no> wrote: > > > >On 1 Aug, 05:10, spop...@speedymail.org (Steve Pope) wrote: > > >> "latticema" -- all-zero filter > > >> "latticear" -- all-pole filter > > >> "latticearma" -- filter with both poles and zeros > > >> Steve > > >Sorry - I got you wrong from the start. I had you down as knowing > > >your DSP. This reveals your true guise as a mere matlab user. > > > Sigh. =A0You're grasping at straws. > > I'm not. Matlab has a very poor repurtation as academic > reference. They used to estimate the length / duration of > the impulse response of IIR filters as the number of > numerator coefficients in the transfer functions (which > works for FIR filters). Their IIR filter design procedures > were screwed up to the point where one needed to 'unteach' > students the matlab blunders before one could teach how > things really were doing. Iterative methods like the > Levinson recursion required users to supply 'true' AR > orders up front, as opposed to supplying a *maximum* order > and then use some order estimator within those constraints. > > At least that was the status when I last used the SP > toolbox around 2004, and had been the status in the 15 years > prior to that time. I know the SP toolbox has been reworked > since then, but I doubdt that more than two decades worth > of flaws, blunders and mistakes are corrected in a hurry. they could begin to fix the blunder of putting the DC component of the fft into X(1). r b-jArticle: 148560
Rune Allnor <allnor@tele.ntnu.no> wrote: >On 1 Aug, 09:50, spop...@speedymail.org (Steve Pope) wrote: >> Personally I am satisfied with this well-known fact from filter theory, >> I feel that the literature is strong enough, and I do not feel on the >> hook to come up with a proof. >Again, I obviously had you wrong. This is a bout maths and >engineering, >not emotions. If you don't 'feel' up to substantiating your position, >don't challenge the points made. Sorry, Rune, but it is you who has provided zero backup for your unsupported negative statements about the lattice filter topology. All I did was tell the OP it would be useful in his case. You haven't come close to explaining to us what, if any, problems there might be with it. >> You haven't supported these statements. If there is a lattice >> topology whose stability depends upon the zero locations, please >> provide a cite for it. (I'm sure such a think might exist. >> But it is not a mainstream topology I would think.) >This is well-known from statistichal DSP. I can't come up >with specifc citations, as my library is is storage and >will remain there for a few weeks to come, Ha! >but I will >tell you what to look for. I know this is treated in the >Proakis & Manolakis general DSP text: > >When dealing with AR models, one can solve the Yule-Walker >equations (or rather, and estimator for these equations) >in any number of ways. Direct solutions through linear algebra >will give you the straight-forward FIR prediction filter; the >Levinson recursion will also give you the reflection coefficients >that go directly into the lattice representation. > >As one would expect, there exist conversion formulae between >the FIR and lattice representations for the AR model: Insert a >set of FIR coefficients and crank out a set of lattice coefficients. >And vice versa. > >The problem is the implicit constraints. In the AR application >the FIR filter is guaranteed to be minimum phase, so its IIR >inverse is causal stable. This translates directly to the >lattice reflection coefficients being constrained to the >interval <-1,1>. > >However, the unsuspecting incompetent user who stumbles across >these conversion formulae and tries to convert a linear phase >FIR to lattice form - don't ask *why* one would want to do this; >I assume the user to be *incompetent* - would end up with a >numerically unstable FIR. Which is a contradiction in terms, >given the entry-level indoctrination matra of DSP. > >Which will only come back to haunt the designer, who exposed >the incompetent user to the lattice structure in the first place. Good, finally some information. The OP was designing a sixth-order Butterworth, not a linear phase FIR, but no matter. SteveArticle: 148561
On Sun, 1 Aug 2010 01:06:16 +0000 (UTC), Giorgos Tzampanakis wrote:
>Where can I find a listing of the features that were added to
>Verilog in the 2001 version, and then of the ones added in
>SystemVerilog?
It's surprisingly hard to extract that information. IEEE
standards conventions strongly discourage the provision
of such "delta" information - the standard is the standard,
that's it - and although the information can be plucked
from reference guides and suchlike it's still not easy.
For example, at one point the Doulos Verilog Golden
Reference Guide highlighted V-2001 features, but in
recent years that disappeared (as V-2001 became the
norm everywhere) and the highlights are now for
newer stuff.
There's a bit of me that asks "why do you want to
know", I suppose. If you need a feature, use it
in your code and then, if the compiler whines at
you, change the compiler switches to use the
newer version! Indeed, one good thing about all
this is that each new version has carefully
preserved back-compatibility with earlier versions,
so in general you lose very little by setting
your tools for the latest version they support.
The obvious drawback to that is that each new
version introduced new keywords. I can't give
you a definitive list, but in V-2001 you
certainly got "generate", "genvar", "signed",
"automatic" and "endgenerate"; if you try to compile
legal V-1995 code that uses these names as identifiers,
of course any V-2001 tool will complain. That's
why the "begin_keywords" and "end_keywords" compiler
directives were added to SystemVerilog: they
don't change the compiler's behaviour, but
they disable recognition of certain keywords
for just that reason.
SystemVerilog adds so much new stuff that it's
almost a new language that happens to include
Verilog as a subset, so I don't think it's
terribly helpful to list the deltas there.
V-2001 versus V-1995 was not so bad. My
non-definitive checklist of changes is...
- So-called "ANSI-style" port lists in which
the whole declaration of a port goes in the
port list. In V-95 the port list was merely
a list of names, and the ports got declared
elsewhere in the code.
- Signed reg and wire declarations, and related
enhancements: signed literal numbers like 2'sb01,
$signed and $unsigned conversions, <<< and >>>
signedness-respecting shift operators.
- Variable initialization as part of its
declaration:
reg [7:0] myVar = 8'd35;
defined to be shorthand for the declaration and
an initial block that does the initialization
- Multi-dimensional arrays of vectors like
wire [7:0] array2D_of_byte [0:5] [0:9];
(but not multi-dimensional ports!)
- Generate if/case/for and genvar
- Localparam, and the parameter port list
module M #(parameter N=5) (input clk, ...);
- always @*
- comma-separated sensitivity lists (as an option
to the "or" operator)
- standardization of the C-style file I/O functions
such as $fscanf; single-channel file descriptors
to support read files
- task automatic, function automatic
- Context-determined width for unsized literals
whose first bit is X or Z
- Standardized C-language algorithms for the
random number generator system functions
In all of this, the only back-compatibility issues
I know about going from V-95 to V-2001 are:
- Changed behaviour of 'bz, 'bx when assigned to a
target with more than 32 bits (but it was almost
certainly a bug in V-95 code anyway)
- Old-style multi-channel file descriptors now support
only a maximum of 30 open files, not 31, because
the MSB of a file descriptor is now a flag to
mark new-style single-channel descriptors
I've no doubt that I will have missed one or two
changes, but that's not a bad list to get you started.
cheers
--
Jonathan Bromley
Article: 148562On 1 Aug, 20:42, spop...@speedymail.org (Steve Pope) wrote: > Rune Allnor =A0<all...@tele.ntnu.no> wrote: > > >On 1 Aug, 09:50, spop...@speedymail.org (Steve Pope) wrote: > >> Personally I am satisfied with this well-known fact from filter theory= , > >> I feel that the literature is strong enough, and I do not feel on the > >> hook to come up with a proof. > >Again, I obviously had you wrong. This is a bout maths and > >engineering, > >not emotions. If you don't 'feel' up to substantiating your position, > >don't challenge the points made. > > Sorry, Rune, but it is you who has provided zero backup for your > unsupported negative statements about the lattice filter topology. =A0 > All I did was tell the OP it would be useful in his case. =A0You > haven't come close to explaining to us what, if any, problems there > might be with it. > > >> You haven't supported these statements. =A0If there is a lattice > >> topology whose stability depends upon the zero locations, please > >> provide a cite for it. =A0(I'm sure such a think might exist. > >> But it is not a mainstream topology I would think.) > >This is well-known from statistichal DSP. I can't come up > >with specifc citations, as my library is is storage and > >will remain there for a few weeks to come, > > Ha! Send me your credit card info, and I will order a copy of P&M - on your expense - to be delivered overnight. Everything is in there. One only needs to read it. > >but I will > >tell you what to look for. I know this is treated in the > >Proakis & Manolakis general DSP text: > > >When dealing with AR models, one can solve the Yule-Walker > >equations (or rather, and estimator for these equations) > >in any number of ways. Direct solutions through linear algebra > >will give you the straight-forward FIR prediction filter; the > >Levinson recursion will also give you the reflection coefficients > >that go directly into the lattice representation. > > >As one would expect, there exist conversion formulae between > >the FIR and lattice representations for the AR model: Insert a > >set of FIR coefficients and crank out a set of lattice coefficients. > >And vice versa. > > >The problem is the implicit constraints. In the AR application > >the FIR filter is guaranteed to be minimum phase, so its IIR > >inverse is causal stable. This translates directly to the > >lattice reflection coefficients being constrained to the > >interval <-1,1>. > > >However, the unsuspecting incompetent user who stumbles across > >these conversion formulae and tries to convert a linear phase > >FIR to lattice form - don't ask *why* one would want to do this; > >I assume the user to be *incompetent* - would end up with a > >numerically unstable FIR. Which is a contradiction in terms, > >given the entry-level indoctrination matra of DSP. > > >Which will only come back to haunt the designer, who exposed > >the incompetent user to the lattice structure in the first place. > > Good, finally some information. ...which is utterly trivial to come by if one is even moderately eductaed on DSP. > The OP was designing a sixth-order Butterworth, not a linear > phase FIR, but no matter. That was what the OP talekd about, yes. Somebody else started wining about lattice structures only being explained on a per application basis. There are very good reasons for that - one needs to know *exactly* what they are used for and why. RuneArticle: 148563
Hallo,
I have just created a driver for a DDR2 working with a Virtex 5 FX30T. I
want to add this driver to a bigger project but I do not know very well how
to modify the constrains file in order to make it work.
I have made some hierarchy modifications to the file but I do not really
get what should I modify... I have tried all I could see coherent.
The error message is the following:
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clk0"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clk90"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clkdiv0"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clk0"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clk90"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clkdiv0"
ERROR:ConstraintSystem:59 - Constraint <NET
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/clk200_ibufg"
ERROR:ConstraintSystem:59 - Constraint <NET "phy_init_done"
ERROR:ConstraintSystem:59 - Constraint <NET "phy_init_done"
ERROR:NgdBuild:604 - logical block 'benchy/persistentdff_inst' with type
after some slight modifications the errors are:
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clk0"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clk90"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clkdiv0"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clk0"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clk90"
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/dcm_clkdiv0"
ERROR:ConstraintSystem:59 - Constraint <NET
ERROR:ConstraintSystem:59 - Constraint <NET
"u_ddr2_infrastructure/clk200_ibufg"
Also I get this message in relation with a test bench I have made in System
Generator and then added to the project:
ERROR:NgdBuild:604 - logical block 'benchy/persistentdff_inst' with type7
The UCF file can be seen in:
http://forums.xilinx.com/xlnx/attachments/xlnx/SYNTHBD/2481/1/ddr2_sdram.ucf
I am pretty newby in this so any help would be appreciated.
Thank you very much in advance :)
Rice.
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 148564On Aug 2, 8:09=A0am, "Rice" <albertopv@n_o_s_p_a_m.hotmail.com> wrote: > Hallo, > > I have just created a driver for a DDR2 working with a Virtex 5 FX30T. I > want to add this driver to a bigger project but I do not know very well h= ow > to modify the constrains file in order to make it work. > > I have made some hierarchy modifications to the file but I do not really > get what should I modify... I have tried all I could see coherent. > > The error message is the following: > > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clk0" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clk90" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clkdiv0" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clk0" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clk90" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clkdiv0" > ERROR:ConstraintSystem:59 - Constraint <NET > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/clk200_ibufg" > ERROR:ConstraintSystem:59 - Constraint <NET =A0"phy_init_done" =A0 =A0 = =A0 =A0 =A0 =A0 =A0 > > ERROR:ConstraintSystem:59 - Constraint <NET =A0"phy_init_done" =A0 =A0 = =A0 =A0 =A0 =A0 =A0 > > ERROR:NgdBuild:604 - logical block 'benchy/persistentdff_inst' with type > > after some slight modifications the errors are: > > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clk0" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clk90" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clkdiv0" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clk0" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clk90" > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/dcm_clkdiv0" > ERROR:ConstraintSystem:59 - Constraint <NET > ERROR:ConstraintSystem:59 - Constraint <NET > "u_ddr2_infrastructure/clk200_ibufg" > > Also I get this message in relation with a test bench I have made in Syst= em > Generator and then added to the project: > > ERROR:NgdBuild:604 - logical block 'benchy/persistentdff_inst' with type7 > > The UCF file can be seen in:http://forums.xilinx.com/xlnx/attachments/xln= x/SYNTHBD/2481/1/ddr2_sd... > > I am pretty newby in this so any help would be appreciated. > > Thank you very much in advance :) > =A0 Rice. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com First of all you're only posting the first line of each error message. I assume you clipped these from the errors tab in ISE. To see the whole message you need to view the translation report file. Second, I expect your problem lies with the hierarchy. If you only have one of these MIG controllers in your system the easy way to fix the .ucf file is to add a wildcard in front of each instance name like: NET "*/u_ddr2_infrastructure/dcm_clk0" . . . It is also possible that you didn't use the same name to instantate the infrastructure module if you didn't start by clipping the code from the example design. So in this case you might need to remove the u_ddr2_infrastructure part of the name and replace it with you instance name. HTH, GaborArticle: 148565
Hi, I have a custom made PCIe board with a Virtex 5 FPGA on which I implemented a DMA unit which uses the PCIe endpoint block plus v1.14. I also implemented simple read/write operations from the PC to the board (the board responds with completion TLPs). The read/write operations are working, DMA is not working (transferring data from FPGA to PC). The board is inserted in a pc with Windows 7 64 bits platform. An application allocates virtual memory and passes a pointer to the memory block to the driver. The driver locks the memory pages and creates a scatter-gather list with physical addresses by using the DMA adapter structure. The physical addresses are written to the FPGA. When I start a DMA operation by writing a register in the FPGA, I can see in chipscope the correct physical addresses in the TLP header (of the memory write requests). However, I do not see the correct values in the allocated memory at the PC. What can I do to check where it is going wrong? In my opinion there are two possibilities: either the TLP is blocked by a PCIe switch at the main board or the data is available at another memory location. I also tried the other direction (send memory read requests TLPs from the FPGA to the PC and receive completion TLPs as answer at the memory read request). In the completion TLPs I see the correct data (data I wrote into the PC memory before starting the DMA operation). Any suggestions/ideas are welcome. Thanks in advance, FrankArticle: 148566
Hi all, I'm implementing an i2c core using FPGA to build interface between DSP and sensors, the objective is to configure the sensors using i2c bus, FPGA first acts as i2c slave and receives all the register data from DSP, then switch as i2c master to send duplicates of register data to several sensors(each sensors receives the same set of register data). I was thinking about using a RAM to store the register data, however, the register address are in 16bits(randomly but not continuously) , the register data are also in 16bits, so I decided to use and LUT table to map the register data to the correspond addresses, it works fine, but it's ressource consuming, it takes almost half of fully used LUT-FF pairs of target FPGA. So I'm wondering if there is any other way to implement the i2c core. Thanks a lot.Article: 148567
Frank van Eijkelenburg <fei.technolution@gmail.com> wrote: > I have a custom made PCIe board with a Virtex 5 FPGA on which I > implemented a DMA unit which uses the PCIe endpoint block plus v1.14. > I also implemented simple read/write operations from the PC to the > board (the board responds with completion TLPs). The read/write > operations are working, DMA is not working (transferring data from > FPGA to PC). (snip) > When I start a DMA operation by writing a register in the FPGA, I can > see in chipscope the correct physical addresses in the TLP header (of > the memory write requests). However, I do not see the correct values > in the allocated memory at the PC. What can I do to check where it is > going wrong? Not having tried to do DMA through PCI before, is data being written, but the wrong data? I would try writing all zeros or all ones and see if those come through fine. It could be timing between the FPGA and PCI such that the wrong data is being latched. Then try slightly less predictable data and see what gets through. -- glenArticle: 148568
On Aug 2, 11:16=A0am, Gladys <yuhu...@gmail.com> wrote: > Hi all, > =A0I'm implementing an i2c core using FPGA to build interface between > DSP and sensors, =A0the objective is to configure the sensors using i2c > bus, FPGA first acts as i2c slave and receives all the register data > from DSP, then switch as i2c master to send duplicates of register > data to several sensors(each sensors receives the same set of register > data). > =A0I was thinking about using a RAM to store the register data, however, > the register address are in 16bits(randomly but not continuously) , > the register data are also in 16bits, so I decided to use and LUT > table to map the register data to the correspond addresses, it works > fine, but it's ressource consuming, it takes almost half of fully used > LUT-FF pairs of target FPGA. So I'm wondering if there is any other > way to implement the i2c core. Thanks a lot. Why not just "record" the i2c commands as they come in from the host, i.e. store the address as well as data as a long stream of bytes into an 8-bit wide block RAM (or go 9 bits wide to mark the start of transactions). Then just "play back" the commands to the slaves. Alternatively use a 32-bit wide block RAM to store address / data pairs. This would only need to be as deep as the total number of registers actually used. Then your address translation isn't necessary. Regards, GaborArticle: 148569
hallo, the constrain related to clk200_ibufg was solved with a modification to the hierarchy in the UCF. The problems related to the dcm were solved just with a Cleanup Project Files. There was no mention to any constrain of them in the UCF so I guess it is a problem related to importing the testbench from System Generator Thank you very much for your time :-D --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148570
Rune Allnor <allnor@tele.ntnu.no> wrote: [lattice filters] >but I will >tell you what to look for. I know this is treated in the >Proakis & Manolakis general DSP text: It is. I'm back in my office today so I have Proakis & Manolakis right in front of me. In the summary at the end of Chapter 9 these authors state: "Finally we mention that lattice and lattice-ladder filter structures are known to be robust in fixed-point implementations." The is what I was attempting to commuicate to the OP for his filter problem, before the discussion got sidetracked. SteveArticle: 148571
On Aug 2, 5:28=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Frank van Eijkelenburg <fei.technolut...@gmail.com> wrote: > > > I have a custom made PCIe board with a Virtex 5 FPGA on which I > > implemented a DMA unit which uses the PCIe endpoint block plus v1.14. > > I also implemented simple read/write operations from the PC to the > > board (the board responds with completion TLPs). The read/write > > operations are working, DMA is not working (transferring data from > > FPGA to PC). > > (snip) > > > When I start a DMA operation by writing a register in the FPGA, I can > > see in chipscope the correct physical addresses in the TLP header (of > > the memory write requests). However, I do not see the correct values > > in the allocated memory at the PC. What can I do to check where it is > > going wrong? > > Not having tried to do DMA through PCI before, is data being > written, but the wrong data? That is what I do not know. Yes the correct data is send to the PC, but if I readout the memory the values are unchanged. > > I would try writing all zeros or all ones and see if those come > through fine. =A0It could be timing between the FPGA and PCI such > that the wrong data is being latched. > > Then try slightly less predictable data and see what gets through. > > -- glen If it was timing, I expect the other way around also problems (which I don't have). Also single memory read/write requests send from the PC are working correctly.Article: 148572
Hi all, See this post: http://jobview.monster.com/Senior-FPGA-Engineer-Job-Weston-FL-89641740.aspx Maybe someone here might be interested. The position seems both challenging and rewarding. Cheers, Jaime ArangurenArticle: 148573
Hello, I am using Virtex 4 FPGA in ML 410 board and ISE 10.1. I want to use PIT interrupt and want to run a subroutine after every 1 second so as to print a statement. May I know how to use PIT interrupt along with code if possible? Regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148574
Hi, i am working on a project where i am developing my architecture on Virtex-4 FPGA. My ultimate goal is to port my design to Xilinx EasyPath FPGA. But i dont have any idea, how xilinx charges for implementing design on EasyPath. there is no guide wither they charge against gate count, or FPGA family. what ever criteria they use, i want some general quotation which can give me idea about pricing. Hoping for quick response. thanks! --------------------------------------- Posted through http://www.FPGARelated.com
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