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
On Mon, 26 Jul 2010 07:04:12 -0700 (PDT), twospruces wrote: >I would like some feedback on a new FPGA architecture. Are there any >serious configurable logic gurus on this group? I'm quite serious, and I'm highly configurable. Whether I'm a logic guru is entirely another matter :-) >If there is interest, I will post links to the 3 published papers that >discuss in detail a logic architecture that offers better than 10x >higher logic density than standard FPGA, along with a significant >reduction in power. If they are "published", in the sense that the information is in the public domain, then you have nothing to lose and all to gain: post the links anyway, and see if you get any bites. If they are under NDA or somesuch, then here is not the place. If you have published without speaking with a good patent lawyer, then your potential investors will likely not be very interested. >The research presents an architecture that can leverage "temporal >logic folding". That's kinda meaningless without the documentation. Is it anything like the stuff Tabula are doing? -- Jonathan BromleyArticle: 148476
On Jul 26, 4:48=A0pm, Andy Peters <goo...@latke.net> wrote: > On Jul 26, 4:53=A0am, "chinnathurai" > > <chinnathurai.c@n_o_s_p_a_m.rediffmail.com> wrote: > > 1.What is a stable clock? > > It's what horses use to tell time. > Thanks for today's best laugh KJArticle: 148477
On Jul 26, 9:49=A0pm, "daniel.lar...@gmail.com"
<daniel.lar...@gmail.com> wrote:
> Hi all,
>
> In my Cyclone 4 based design I'm getting an embedded multiplier
> inferred, as expected from the following VHDL:
>
> C <=3D A * B;
>
> (where A and B are registered 12 bit values, and the output C is
> subsequently registered, with no other logic in the path)
>
> However I'm seeing a timing violation on this path. Looking at the
> timing reports, there is nearly a 2ns delay between the output of the
> multiplier and the flop. Obviously I'd really like to pull in some of
> this 2ns, which would sort out the negative slack problem.
>
> I looked through the documentation for the embedded multipliers, and
> as expected there are input and output registers as part of the
> embedded multiplier block. But clearly with that 2ns delay the output
> register isn't being used. So my question is: how do I write my code
> to infer the use of the output registers in the embedded multipliers?
> As I tried a number of coding styles, including putting the
> multiplication operation directly inside a clocked process and it had
> no impact on timing. But I definitely don't want to instantiate the
> embedded multiplier directly. =A0Perhaps there are any VHDL attributes
> that may help (anything other than MULTSTYLE =A0DSP/LOGIC)?
>
> Any suggestions or pointers to documents would be greatly appreciated!
I would try this
Mult: process (iClk, inResetAsync) is
begin
if inResetAsync =3D '0' then
C <=3D (others =3D> '0');
elsif rising_edge(iClk) then -- rising clock edge
C <=3D A * B;
end if;
end process Mult;
Article: 148478Andrew Feldhaus <Reply@thread.pls> writes: > Hi, > > As I understand it, good practice dictates that in a synthesis-targeted > setting, components should use ports of type std_logic or std_logic_vector > only. I'd disagree. I use numeric (and other) types all the time on component ports (integers, unsigneds, records...). Only on the topmost entity do I stick to std_logic(_vector)s throughout - simply because it means I can drop the post-synth or post-PAR netlist straight into my topmost testbench without having to faff around writing a wrapper. > > Certainly Xilinx's IP generation tools provide components with this > philosophy. > Hmmm, yes. They also produce use "ieee.std_logic_arith.all" clauses by default (unless that changed in 12.1). They (vendors' example code) are not the best place to find best-practise :) > My design is well-suited to the use of signed types from IEEE.Numeric_Std. > By all means use them - I don't think XST has a problem synthesising them. I've snipped the rest of your, post, as I think you're better off using the appropriate types, rather than trying to force them all to by std_logics (But I can't see anything wrong with what you've done either.) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 148479
I thought I'd already tried that - but it looks like I forgot to reset the output (i.e. C in this case), which subsequently gave a result which didn't use the output register. Problem solved now - Thanks > I would try this > > Mult: process (iClk, inResetAsync) is > =A0 begin > =A0 =A0 if inResetAsync =3D '0' then > =A0 =A0 =A0 C <=3D (others =3D> '0'); > =A0 =A0 elsif rising_edge(iClk) then =A0 =A0 -- rising clock edge > =A0 =A0 =A0 C <=3D A * B; > =A0 =A0 end if; > =A0 end process Mult;Article: 148480
> I thought I'd already tried that - but it looks like I forgot to reset > the output (i.e. C in this case), which subsequently gave a result > which didn't use the output register. Problem solved now - Thanks That's odd, I'd have expected the output to have been registered whether it was asynchronously reset or not. Is this a bug in the synthesis tool? Nial.Article: 148481
Hi,
I'm trying to debug a Cyclone design which writes values taken from a
lookup table to the address inputs of a crosspoint analog switch. The
problem is that everything looks OK in the Quartus simulator, but when
I test the design on the target hardware it seems to be pulling the
wrong values out of the LUT. I have tried enabling SignalTap and
probing the output pins during the write operation, SignalTap reports
correct operation but the outputs, as measured on a real logic
analyser, are wrong.
E.g. for CHANNEL=1, eeprom_en='0', path=0 I should get 0,0,0,0,B,A,
3,2, I actually get 0,0,0,0,9,8,3,2
The lookup table is implemented thus:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity xpswitch is
generic(PLL_CLK_FREQ : integer;
CHANNEL : integer);
port(
pll_clk : in std_logic;
sys_rst : in std_logic;
path_index : in integer range 0 to 7;
eeprom_en : in std_logic;
go : in std_logic;
busy : out std_logic;
AX : out std_logic_vector(3 downto 0);
AY : out std_logic_vector(2 downto 0);
CS : out std_logic;
DAT : buffer std_logic;
RST : out std_logic;
STRB : out std_logic
);
end xpswitch;
architecture rtl of xpswitch is
type t_ax_lut is array(0 to 7) of std_logic_vector(3 downto
0);
signal ax_lut : t_ax_lut;
signal ay_count : integer range 0 to 7;
begin
p_lut : process(eeprom_en, path_index) begin
case CHANNEL is
when 1 =>
if(eeprom_en = '1') then
case path_index is
when 0 => ax_lut <=
(x"7", x"6", x"8", x"9", x"B", x"A", x"3",x"2");
when 1 => ax_lut <=
(x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0");
when 2 => ax_lut <=
(x"7", x"6", x"8", x"9", x"4", x"5", x"E",x"F");
when 3 => ax_lut <=
(x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0");
when 4 => ax_lut <=
(x"7", x"6", x"8", x"9", x"3", x"2", x"B",x"A");
when 5 => ax_lut <=
(x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0");
when 6 => ax_lut <=
(x"7", x"6", x"8", x"9", x"E", x"F", x"4",x"5");
when 7 => ax_lut <=
(x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0");
end case;
else
case path_index is
when 0 => ax_lut <=
(x"0", x"0", x"0", x"0", x"B", x"A", x"3",x"2");
when 1 => ax_lut <=
(x"0", x"0", x"0", x"0", x"9", x"8", x"6",x"7");
when 2 => ax_lut <=
(x"0", x"0", x"0", x"0", x"4", x"5", x"E",x"F");
when 3 => ax_lut <=
(x"0", x"0", x"0", x"0", x"6", x"7", x"9",x"8");
when 4 => ax_lut <=
(x"0", x"0", x"0", x"0", x"3", x"2", x"B",x"A");
when 5 => ax_lut <=
(x"0", x"0", x"0", x"0", x"9", x"8", x"6",x"7");
when 6 => ax_lut <=
(x"0", x"0", x"0", x"0", x"E", x"F", x"4",x"5");
when 7 => ax_lut <=
(x"0", x"0", x"0", x"0", x"6", x"7", x"9",x"8");
end case;
end if;
when 2 =>
if(eeprom_en = '1') then
case path_index is
when 0 => ax_lut <=
(x"3", x"2", x"A", x"B", x"8", x"9", x"7",x"6");
when 1 => ax_lut <=
(x"0", x"0", x"0", x"0", x"8", x"9", x"7",x"6");
when 2 => ax_lut <=
(x"E", x"F", x"5", x"4", x"8", x"9", x"7",x"6");
when 3 => ax_lut <=
(x"0", x"0", x"0", x"0", x"8", x"9", x"7",x"6");
when 4 => ax_lut <=
(x"B", x"A", x"2", x"3", x"8", x"9", x"7",x"6");
when 5 => ax_lut <=
(x"0", x"0", x"0", x"0", x"8", x"9", x"7",x"6");
when 6 => ax_lut <=
(x"4", x"5", x"F", x"E", x"8", x"9", x"7",x"6");
when 7 => ax_lut <=
(x"0", x"0", x"0", x"0", x"8", x"9", x"7",x"6");
end case;
else
case path_index is
when 0 => ax_lut <=
(x"3", x"2", x"A", x"B", x"0", x"0", x"0",x"0");
when 1 => ax_lut <=
(x"6", x"7", x"8", x"9", x"0", x"0", x"0",x"0");
when 2 => ax_lut <=
(x"E", x"F", x"5", x"4", x"0", x"0", x"0",x"0");
when 3 => ax_lut <=
(x"9", x"8", x"7", x"6", x"0", x"0", x"0",x"0");
when 4 => ax_lut <=
(x"B", x"A", x"2", x"3", x"0", x"0", x"0",x"0");
when 5 => ax_lut <=
(x"6", x"7", x"8", x"9", x"0", x"0", x"0",x"0");
when 6 => ax_lut <=
(x"4", x"5", x"F", x"E", x"0", x"0", x"0",x"0");
when 7 => ax_lut <=
(x"9", x"8", x"7", x"6", x"0", x"0", x"0",x"0");
end case;
end if;
when 3 =>
if(eeprom_en = '1') then
case path_index is
when 0 => ax_lut <=
(x"B", x"A", x"6", x"7", x"4", x"5", x"3",x"2");
when 1 => ax_lut <=
(x"0", x"0", x"0", x"0", x"4", x"5", x"3",x"2");
when 2 => ax_lut <=
(x"8", x"9", x"F", x"E", x"4", x"5", x"3",x"2");
when 3 => ax_lut <=
(x"0", x"0", x"0", x"0", x"4", x"5", x"3",x"2");
when 4 => ax_lut <=
(x"7", x"6", x"A", x"B", x"4", x"5", x"3",x"2");
when 5 => ax_lut <=
(x"0", x"0", x"0", x"0", x"4", x"5", x"3",x"2");
when 6 => ax_lut <=
(x"E", x"F", x"9", x"8", x"4", x"5", x"3",x"2");
when 7 => ax_lut <=
(x"0", x"0", x"0", x"0", x"4", x"5", x"3",x"2");
end case;
else
case path_index is
when 0 => ax_lut <=
(x"B", x"A", x"6", x"7", x"0", x"0", x"0",x"0");
when 1 => ax_lut <=
(x"5", x"4", x"3", x"2", x"0", x"0", x"0",x"0");
when 2 => ax_lut <=
(x"8", x"9", x"F", x"E", x"0", x"0", x"0",x"0");
when 3 => ax_lut <=
(x"2", x"3", x"4", x"5", x"0", x"0", x"0",x"0");
when 4 => ax_lut <=
(x"7", x"6", x"A", x"B", x"0", x"0", x"0",x"0");
when 5 => ax_lut <=
(x"5", x"4", x"3", x"2", x"0", x"0", x"0",x"0");
when 6 => ax_lut <=
(x"E", x"F", x"9", x"8", x"0", x"0", x"0",x"0");
when 7 => ax_lut <=
(x"2", x"3", x"4", x"5", x"0", x"0", x"0",x"0");
end case;
end if;
when others =>
end case;
end process;
AX <= ax_lut(ay_count);
There are 3 instances of this code in the design, with different
switch mappings selected by the CHANNEL parameter. They all show the
same problem, 'B','A' is consistently replaced by '9','8'.
I can't resolve this discrepancy I'm seeing between what the tools are
telling me and the behaviour when running on the target. The internal
PLL is being used to generate a 57.6 MHz global clock; Quartus timing
analysis shows f_max as about 85 MHz so i don't think it is a timing
issue. I have checked the pin assignments by driving the AX outputs
with a 4-bit counter which cycles continuously, this works correctly
as seen on the simulator and the external logic analyser.
Any ideas? I have raised a support case with Altera, no response as
yet.
TIA
R.
Article: 148482On 27 Jul., 09:57, Martin Thompson <martin.j.thomp...@trw.com> wrote: > Andrew Feldhaus <Re...@thread.pls> writes: > > Hi, > > > As I understand it, good practice dictates that in a synthesis-targeted > > setting, components should use ports of type std_logic or std_logic_vector > > only. Why? Todays FPGAs don't even have tristate buffers internally so STD_ULOGIC is clearly more appropriate than STD_LOGIC. It simulates faster and there are bugs that can be found by the synthesis tools earlier in the build process (i.e. signals with multiple drivers) SIGNED and UNSIGNED are subtypes of STD_LOGIC, so there should be no issue whatsoever in synthesizing them. Some synthesis tools throw away the type information when creating timing simulation models and replace them with STD_LOGIC which clearly is a bug of the tools. It is very easy to write a Perl script that puts the type information back in so there plainly is no excuse for the tools to do that. KoljaArticle: 148483
Hey Folks, I am trying to implemented an all digital PLL on Xilinx FPGAs. First, I wrote some Matlab code to see the functionality of the PLL. Everything seemed to work fine. Then I quantized the operations in Matlab to find out the amount of precision I need in hardware. That's when the PLL stopped working, or started oscillating! It seems to me that every part of the PLL is OK with fixed precession, i.e. 20 bits, except for the Loop Filter which needs to be double-precession. One reason can be the fact that Loop Filter coefficients are very small numbers so their effect is not preserved in finite precession. Since my target is FPGA, I don't have any idea how to implement double- precession function. Or, is it even possible? I wondered if any of you has any kind of experience with digital PLLs or double precession operations in FPGAs. Thank you!Article: 148484
On 07/27/2010 09:38 AM, Ehsan wrote: > Hey Folks, > > I am trying to implemented an all digital PLL on Xilinx FPGAs. First, > I wrote some Matlab code to see the functionality of the PLL. > Everything seemed to work fine. Then I quantized the operations in > Matlab to find out the amount of precision I need in hardware. That's > when the PLL stopped working, or started oscillating! It seems to me > that every part of the PLL is OK with fixed precession, i.e. 20 bits, > except for the Loop Filter which needs to be double-precession. One > reason can be the fact that Loop Filter coefficients are very small > numbers so their effect is not preserved in finite precession. Since > my target is FPGA, I don't have any idea how to implement double- > precession function. Or, is it even possible? I wondered if any of you > has any kind of experience with digital PLLs or double precession > operations in FPGAs. I assume you mean double-precision floating point when you say "double-precession"? It's not necessary. One generally needs more precision in the loop filter (specifically in the integrator in the loop filter) than one does anywhere else, but one can still keep things as fixed-point numbers. Nearly everyone I know who's implemented a digital PLL knows in their heart that there's only one unique kind; which one of the many unique kinds of digital PLL there are seems to depend on what industry you're from, or even what company you've worked for. So tell us more about the one unique kind of digital PLL architecture that you're working on and we may be able to help. What are you trying to achieve? Frequency synthesis? Lock an oscillator (or motor) to an external source? Synchronize to a carrier in a communications system? Are you trying to stabilize a noisy oscillator to a stable reference, or are you trying to smooth out the phase and frequency of a noisy reference while preserving the underlying DC behavior? What are you using for an oscillator? A 'traditional' phase-incrementing NCO? A counter with a varying target or load value? An external XCO driven by a DAC? A motor driven by a DAC? What are you using for a phase detector? What are you using for a loop filter? Just a PI filter? PI filter + low pass? Something fancy? -- 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: 148485
I haven't used Altera tools for ages, but I'm working on a Cyclone 3 design now, so I'm trying to understand them. The design is going to use many 20x20 signed multipliers. I had hoped that the synthesizer would be able to infer a 20 x 20 that used one 18 x 18, and did the rest in fabric, but I couldn't get that to work. I used the MegaWizard with the LPM_MULT. I set the Optimization to "Area" (otherwise it uses nothing but hardware multipliers) and set the latency to three (to allow some pipelining for the addition of the two 2x20 mults in fabric) and it seems to do pretty much what I expected. That was with Quartus 9.1. If I try to repeat this with Quartus 10, it won't let me set the latency to three. If I set it to two it does what I would expect, and runs too slow (as I would expect). Any idea what's going on? Am I being dumb, or are the tools broken? Is there some resource at Altera that I should be using for questions like these. I tried using the FAE at the client's distributor, but that was an annoying waste of time. Thanks PeteArticle: 148486
On 2010-07-21, Markus Lavin <markusl.se78pleasenospam@gmail.com> wrote: > Hi all, > > This is a post to announce the existence of the AjarDSP project, an > attempt to design and implement an open source VLIW DSP with an open > source tool chain (assembler, simulator/debugger and C compiler). > > Check out the details at: http://code.google.com/p/ajardsp/ This sounds very interesting. I have contemplated doing something similar a long time as there were no FPGA optimized DSP processor available that I'm was aware of, but in the end I got stuck creating a fairly general purpose FPGA optimized processor instead. Are you doing this just for fun or do you have some specific applications in mind? /AndreasArticle: 148487
crappy hex stuff trimmed by site managerArticle: 148488
Hey, I have to implement a RS-Latch. I know that it is not a good design practice but because of limited clocks, I have to use it. Now my concerns are that this latch could go metastable. In my design, the reset and set input of the latch are not set simultaneously. But before the set input there is a AND gate which is fed by asynchronous inputs. Thus it is possible that the set input of the RS-Latch is set by a runt pulse or anything between '0' and '1'. So, my question is, if my concerns are legitimated?Article: 148489
On Jul 27, 9:38=A0am, Ehsan <ehsan.hosse...@gmail.com> wrote: > Hey Folks, > > I am trying to implemented an all digital PLL ... > > Thank you! You might take a look at the discussion of precision and bit alignment here: http://www.compdsp.com/presentations/Jacobsen/abineau_dpll_analysis.pdf Dale B. DalrympleArticle: 148490
On Jul 27, 11:57=A0am, Tim Wescott <t...@seemywebsite.com> wrote: > On 07/27/2010 09:38 AM, Ehsan wrote: > > > I assume you mean double-precision floating point when you say > "double-precession"? =A0It's not necessary. =A0One generally needs more > precision in the loop filter (specifically in the integrator in the loop > filter) than one does anywhere else, but one can still keep things as > fixed-point numbers. > > Nearly everyone I know who's implemented a digital PLL knows in their > heart that there's only one unique kind; which one of the many unique > kinds of digital PLL there are seems to depend on what industry you're > from, or even what company you've worked for. > > So tell us more about the one unique kind of digital PLL architecture > that you're working on and we may be able to help. > > What are you trying to achieve? =A0Frequency synthesis? =A0Lock an > oscillator (or motor) to an external source? =A0Synchronize to a carrier > in a communications system? =A0Are you trying to stabilize a noisy > oscillator to a stable reference, or are you trying to smooth out the > phase and frequency of a noisy reference while preserving the underlying > DC behavior? > > What are you using for an oscillator? =A0A 'traditional' > phase-incrementing NCO? =A0A counter with a varying target or load value? > =A0 An external XCO driven by a DAC? =A0A motor driven by a DAC? > > What are you using for a phase detector? > > What are you using for a loop filter? =A0Just a PI filter? =A0PI filter + > low pass? =A0Something fancy? > > -- > > Tim Wescott > Wescott Design Serviceshttp://www.wescottdesign.com > > Do you need to implement control loops in software? > "Applied Control Theory for Embedded Systems" was written for you. > See details athttp://www.wescottdesign.com/actfes/actfes.html Thank you Tim. I'm trying to use the PLL for timing synchronization in a communication receiver. The Loop filter is simply a PI filter with two coefficients, i.e. C1 and C2. I can write the filter equation for you: y[n] =3D C1*x[n] + (C2-C1)*x[n-1] + y[n-1] For the phase detector, I am using an Early/Late error detector which simply uses the time difference of two adjacent samples to generate error signal. The VCO is a counter which is decremented according to the output of the loop filter. I hope this could help you to have a picture of my PLL in your mind.Article: 148491
Jonathan Bromley wrote: > That's kinda meaningless without the documentation. Is it > anything like the stuff Tabula are doing? I don't know. But searching for "temporal logic folding" results in this article (article creation date: august 2009) : http://mcwang.net/files/NATURE_Article.pdf Sounds interesting, but I guess it needs some more years of research before it is usable in a product and it doesn't help for all FPGA problems, because the space advantage has a speed penalty. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 148492
On Jul 27, 2:41=A0pm, firefox3107 <firefox3...@gmail.com> wrote: > Hey, > > I have to implement a RS-Latch. I know that it is not a good design > practice but because of limited clocks, I have to use it. > Now my concerns are that this latch could go metastable. In my design, > the reset and set input of the latch are not set simultaneously. But > before the set input there is a AND gate which is fed by asynchronous > inputs. Thus it is possible that the set input of the RS-Latch is set > by a runt pulse or anything between '0' and '1'. > > So, my question is, if my concerns are legitimated? What sort of device is this going into? In the older Xilinx families RS latches are simply made with D flip-flops using both asynchronous set and reset. Newer devices only have a choice of either set or reset and therefore cause the latch to be built some other way, which will not have as good timing. As to the AND gate, unless the device is broken, there should be no runt pulses unless there is an actual overlap time when all inputs are high (as seen at the gate inputs, which may be after significant routing delays). Inside the FPGA, signals don't spend much time "between '0' and '1'", so I don't see where you're going with that... Regards, GaborArticle: 148493
On Jul 27, 2:41=A0pm, firefox3107 <firefox3...@gmail.com> wrote: > Hey, > > I have to implement a RS-Latch. I know that it is not a good design > practice but because of limited clocks, I have to use it. The 'limited clocks' statement doesn't make much sense. The only reason to not use a flop in this instance is if the time that the 'R' or the 'S' is active is less than the period of whatever clock(s) you might have. Is that really the case? Is there really nothing you can do to extend the length of time that 'R' or 'S' are active so that they are guaranteed to be at least one clock cycle wide? > Now my concerns are that this latch could go metastable. In my design, > the reset and set input of the latch are not set simultaneously. But > before the set input there is a AND gate which is fed by asynchronous > inputs. Thus it is possible that the set input of the RS-Latch is set > by a runt pulse or anything between '0' and '1'. > > So, my question is, if my concerns are legitimated? Probably...maybe not necessarily metastability, but also consider race conditions in which the 'R' or 'S' gets set momentarily because of the async logic that generates 'R' and 'S'. Asynchronous logic feeding sets/resets/clocks in FPGAs can be dicey if not done properly and is always something to: - Look at very closely to see if there is a synchronous way to do it instead - Look at the timing analysys very closely...it is very easy to be misled here also which leads to thinking that you're right when you're really wrong. Kevin JenningsArticle: 148494
On 07/27/2010 12:39 PM, Ehsan wrote: > On Jul 27, 11:57 am, Tim Wescott<t...@seemywebsite.com> wrote: >> On 07/27/2010 09:38 AM, Ehsan wrote: >> >> >> I assume you mean double-precision floating point when you say >> "double-precession"? It's not necessary. One generally needs more >> precision in the loop filter (specifically in the integrator in the loop >> filter) than one does anywhere else, but one can still keep things as >> fixed-point numbers. >> >> Nearly everyone I know who's implemented a digital PLL knows in their >> heart that there's only one unique kind; which one of the many unique >> kinds of digital PLL there are seems to depend on what industry you're >> from, or even what company you've worked for. >> >> So tell us more about the one unique kind of digital PLL architecture >> that you're working on and we may be able to help. >> >> What are you trying to achieve? Frequency synthesis? Lock an >> oscillator (or motor) to an external source? Synchronize to a carrier >> in a communications system? Are you trying to stabilize a noisy >> oscillator to a stable reference, or are you trying to smooth out the >> phase and frequency of a noisy reference while preserving the underlying >> DC behavior? >> >> What are you using for an oscillator? A 'traditional' >> phase-incrementing NCO? A counter with a varying target or load value? >> An external XCO driven by a DAC? A motor driven by a DAC? >> >> What are you using for a phase detector? >> >> What are you using for a loop filter? Just a PI filter? PI filter + >> low pass? Something fancy? >> >> -- >> >> Tim Wescott >> Wescott Design Serviceshttp://www.wescottdesign.com >> >> Do you need to implement control loops in software? >> "Applied Control Theory for Embedded Systems" was written for you. >> See details athttp://www.wescottdesign.com/actfes/actfes.html > > > Thank you Tim. I'm trying to use the PLL for timing synchronization in > a communication receiver. The Loop filter is simply a PI filter with > two coefficients, i.e. C1 and C2. I can write the filter equation for > you: > > y[n] = C1*x[n] + (C2-C1)*x[n-1] + y[n-1] > > For the phase detector, I am using an Early/Late error detector which > simply uses the time difference of two adjacent samples to generate > error signal. > The VCO is a counter which is decremented according to the output of > the loop filter. > > I hope this could help you to have a picture of my PLL in your > mind. If I'm getting my math right your loop filter is equivalent to u[n] = u[n-1] + C2 * x[n], y[n] = u[n] + (C1-C2) * x[n]. This not only has the advantage of not requiring you to store prior values of the input, it should also let you separate the math around the integrator state (u) which will need to be fairly high precision from the proportional section. Figure that u[n] needs to resolve the smallest value in x[n] times C2, and that C2 will be several powers of two smaller than 1, most likely -- certainly it'll be several powers of two smaller than C1. -- 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: 148495
Hi, I wanna get started to design architectures with partially reconfiguarable modules. I am using a Virtex-5, according to the manual this board now also allows to dyanmically change the clock using the DRP port. The way to implement partially reconfigurable logic blocks seems to be described in this document: http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_1/ug702.pdf I assume this is the state-of-the-art since it has been recently purchased. I am wondering if somebody has maybe additional ressources that are helpful to get started with this topic. In particular a very simple would be very helpful to get a deeper insight how it works. The ultimate goal is then to have a design the partially changes it reconfiguration depending on the input. Silly question: From where will the partial modules be loaded? From Flash or are the somehow requested over the JTAG interface when they are required? Many thanks for your help, RichArticle: 148496
On Jul 28, 7:39=A0am, Ehsan <ehsan.hosse...@gmail.com> wrote: > The VCO is a counter which is decremented according to the output of > the loop filter. Err, a Counter is not a VCO ? This will give you a choice of quantized frequency outputs, and the control loop will need to choose a weighted ratio, that averages to your desired frequency. Is the quantize and jitter tolerable in your application ? -jgArticle: 148497
On Jul 26, 8:49=A0pm, "daniel.lar...@gmail.com" <daniel.lar...@gmail.com> wrote: > Hi all, > > In my Cyclone 4 based design I'm getting an embedded multiplier > inferred, as expected from the following VHDL: > > C <=3D A * B; > > (where A and B are registered 12 bit values, and the output C is > subsequently registered, with no other logic in the path) > > However I'm seeing a timing violation on this path. Looking at the > timing reports, there is nearly a 2ns delay between the output of the > multiplier and the flop. Obviously I'd really like to pull in some of > this 2ns, which would sort out the negative slack problem. > > I looked through the documentation for the embedded multipliers, and > as expected there are input and output registers as part of the > embedded multiplier block. But clearly with that 2ns delay the output > register isn't being used. So my question is: how do I write my code > to infer the use of the output registers in the embedded multipliers? > As I tried a number of coding styles, including putting the > multiplication operation directly inside a clocked process and it had > no impact on timing. But I definitely don't want to instantiate the > embedded multiplier directly. =A0Perhaps there are any VHDL attributes > that may help (anything other than MULTSTYLE =A0DSP/LOGIC)? > > Any suggestions or pointers to documents would be greatly appreciated! The following works, I have 10's of thousands of instantions in a similar number of FPGA's actually in the field. The multstyle attribute may be what you need. Synthesis might not use DSP if there is not timing need and no power need. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D-- -- COPYRIGHT (c) 2010 DAVID GREIG. This source file is the property of David Greig. This work must not be copied without permission from David Greig. -- -- Any copy or derivative of this source file must include this copyright statement. -- ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------- -- File : SyS_Mult.vhd -- Author : David Greig (email : -- Revision : -- Description : signed input data multiplier with clken output reg ---------------------------------------------------------------------------= --------------------------------------------- -- Notes : 2 clock cycle delay -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D-- library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D-- entity SyS_Mult is -- 2 clock cycle delay generic( Gdawidth : natural; Gdbwidth : natural; Gmult_pref : string ); port( arstn : in std_logic; clk : in std_logic; clken : in std_logic; da_i : in std_logic_vector(Gdawidth - 1 downto 0); db_i : in std_logic_vector(Gdbwidth - 1 downto 0); q_o : out std_logic_vector(Gdawidth + Gdbwidth - 1 downto 0) ); end entity SyS_Mult; -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D-- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~-- architecture rtl of SyS_Mult is -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~-- attribute multstyle : string; -- Implementation style, "logic" "dsp" --------------------------------------------------------------------------= ---------------------------------------------- signal da_r : signed(Gdawidth - 1 downto 0); signal db_r : signed(Gdbwidth - 1 downto 0); signal p_r : signed(Gdawidth + Gdbwidth - 1 downto 0); attribute multstyle of p_r : signal is Gmult_pref; ---------------------------------------------------------------------------= --------------------------------------------- begin ---------------------------------------------------------------------------= --------------------------------------------- prcs_SyS_Mult : process(arstn, clken, clk) begin if (arstn =3D '0') then da_r <=3D (others =3D> '0'); db_r <=3D (others =3D> '0'); p_r <=3D (others =3D> '0'); elsif (clken =3D '0') then null; elsif rising_edge(clk) then da_r <=3D signed(da_i); db_r <=3D signed(db_i); p_r <=3D (da_r * db_r); end if; end process prcs_SyS_Mult; --------------------------------------------------------------------------= ---------------------------------------------- q_o <=3D std_logic_vector(p_r); -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~-- end architecture rtl; -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~-- -- component SyS_Mult is -- 2 clock cycle delay -- generic( -- Gdawidth : natural; -- Gdbwidth : natural; -- Gmult_pref : string -- ); -- port( -- arstn : in std_logic; -- clk : in std_logic; -- clken : in std_logic; -- da_i : in std_logic_vector(Gdawidth - 1 downto 0); -- db_i : in std_logic_vector(Gdbwidth - 1 downto 0); -- q_o : out std_logic_vector(Gdawidth + Gdbwidth -1 downto 0) -- ); -- end component SyS_Mult; -- i_ : SyS_Mult -- 2 clock cycle delay -- generic map( -- Gdawidth =3D> , -- Gdbwidth =3D> , -- Gmult_pref =3D> -- ) -- port map( -- arstn =3D> , -- clk =3D> , -- clken =3D> , -- da_i =3D> , -- db_i =3D> , -- q_o =3D> -- );Article: 148498
OK, following some advice elsewhere re inferred ROMs I have re-worked
the lookup table as a nested array:
type t_ax_by_ay is array(0 to 7) of std_logic_vector(3 downto 0);
type t_ax_by_path is array(0 to 7) of t_ax_by_ay;
type t_ax_by_e_en is array(0 to 1) of t_ax_by_path;
type t_ax_by_chan is array(0 to 2) of t_ax_by_e_en;
constant AX_LUT : t_ax_by_chan :=
((((x"0", x"0", x"0", x"0", x"B", x"A", x"3", x"2"),
...
...
Then registered the output (the inputs are driven by registers in the
parent block of code, one global clock used for everything):
p_lut : process(pll_clk) begin
if(pll_clk'event and pll_clk = '1') then
ax_lut_out <= AX_LUT(CHANNEL)(ee_en)(path_index)(ay_count);
end if;
end process;
Result : Exactly the same!
When declaring arrays of constants, are the elements guaranteed to be
assigned in the order they are declared? Only I came across this bit
of example code
http://mysite.ncnetwork.net/reszotzl/sync_rom.vhd
where the position of each element within the array is explicitly
given. If I don't do this, is the compiler allowed to re-order the
elements to minimize the logic?
Thanks
R.
Article: 148499
On Wed, 28 Jul 2010 02:46:40 -0700 (PDT), Rhydian <news@rblack01.plus.com>
wrote:
>OK, following some advice elsewhere re inferred ROMs I have re-worked
>the lookup table as a nested array:
>
>type t_ax_by_ay is array(0 to 7) of std_logic_vector(3 downto 0);
>type t_ax_by_path is array(0 to 7) of t_ax_by_ay;
>
>Result : Exactly the same!
>
>When declaring arrays of constants, are the elements guaranteed to be
>assigned in the order they are declared? Only I came across this bit
>of example code
>
>http://mysite.ncnetwork.net/reszotzl/sync_rom.vhd
>
>where the position of each element within the array is explicitly
>given. If I don't do this, is the compiler allowed to re-order the
>elements to minimize the logic?
Explicitly giving the position ("named association") can add clarity or
readability to a design, but for a large ROM like yours is likely to just add
clutter.
In its absence the compiler CANNOT re-order elements; they are guaranteed to be
in the order given.
(There are more complex rules regarding mixing named and positional association
in the same array but don't worry about that here!)
You did say the design exhibits correct behaviour - is it possible that
synthesis has found and eliminated some redundant logic?
I would ask if synthesis or mapping has concluded that one bit of your array is
redundant, e.g. because it doesn't feed any logic - or because that piece of
logic hasn't been implemented yet - or because it contains a design error - or
because it hasn't been connected to any I/O pins yet - or any of the sometimes
mysterious reasons why synthesis trims logic.
This might appear as obscure clues in synthesis or mapping reports.
Alternatively, a chain of XORs across the ROM output, tied to a spare output
pin, may prevent the optimisation, as an experiment to see what is really going
on..
- Brian
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